Vehicle identification card

ABSTRACT

A vehicle identification card is provided to an insured that includes proof of automotive insurance information and charge account information. The card may include an insurance policy covering the insured&#39;s vehicle, the VIN number of the vehicle, and other information about the vehicle such as the vehicle&#39;s make and model. The card may include account information that allows the card to be used like a credit card. The card may further include means for wirelessly updating information and providing a display to the user, which includes, but is not limited to, a housing, a memory module, a processor, one or more displays, and a power source.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/758,712, filed on Feb. 4, 2013, which is a continuation of U.S.patent application Ser. No. 11/861,476, now U.S. Pat. No. 8,370,254,filed on Sep. 26, 2007, each of which is incorporated herein byreference in its entirety.

BACKGROUND

Consumers are often in need of account and other information regardingtheir various debit/credit cards. This may include items such as accountstatus, available balance and other information. Currently, card holderseither call or log on to their account over the internet to get thedesired information regarding their account. Also, financialinstitutions and card issuers are in constant searches for new andeffective ways to get relevant information to their card holders such asoffers for new products and other marketing information that may be ofinterest to particular customers. Currently, the main forms ofcommunication between the card holders and the financial institutions isby phone, mail, or internet. These methods are often inconvenient andcostly.

Also, there are numerous pieces of personal that a person must be ableto access in a timely manner. However, this type of information is oftenlocated on cards that expire, and this information may change morefrequently than the card expires. Additionally or alternatively, suchinformation may be too important or sensitive to carry around withoneself at all times, as such information may be acquired by a thirdparty simply by possessing or viewing the card. Thus, there is a needfor technology that can safely provide current information related totransaction cards.

SUMMARY

In various embodiments of the present disclosure, a vehicleidentification card is provided, e.g. to an insured, that includes proofof automotive insurance information and charge account information. Thevehicle identification card may include an insurance policy covering theinsured's vehicle, the VIN number of the vehicle, and other informationabout the vehicle such as the vehicle's make and model. The vehicleidentification card may include account information that allows thevehicle identification card to be used like a credit card.

In another embodiment, a wirelessly updated vehicle identification cardis provided, which includes, but is not limited to, a housing; a memorymodule integrated with the housing; a processor coupled to the memorymodule; one or more displays integrated with the housing operablycoupled to the processor; a transceiver integrated with the housingconfigured to wirelessly receive account information from a remotedevice over a cellular network; and a power source integrated with thehousing operably coupled to the memory module, the processor, thetransceiver, and the one or more displays.

In further embodiments, a system is provided that can monitor thetransactions utilized by the vehicle identification card in order tocreate indicators for the insured, such as messages that can be viewedon the card's display while the insured is checking their account. Theindicators can be notifications or advertisements related to thepurchases the insured makes or related to the vehicle the insured owns.Some of the displays can include coupons for the insured for maintainingtheir vehicle. A history of vehicle related transactions can be createdand can be downloaded by the insured, a company, or a person who wantsto purchase the vehicle.

The system may also include an additional credit line that can be usedto make vehicle related purchases. The credit line may be utilized by anagent of the insurance company. If the user is in an accident they cancall their insurance agent, for example. The agent can gather the factssurrounding the accident and determine how much money the insurancecompany will give the insured to fix their vehicle. This money can beplaced in the account of the user as an additional credit line or as acredit to the account of the insured. The insured may then fix theirvehicle and utilize the credit line or the additional credit to pay forthe repairs to their vehicle. The system may release the funds undercertain conditions, for example, the system may only release the fundsto a certain company, for a certain repair, or if the user is satisfiedwith the repairs. All of the above accounts may be viewed on the vehicleidentification card.

It can be appreciated by one of skill in the art that one or morevarious aspects of the disclosure may include, but are not limited to,circuitry and/or programming for effecting the herein-referencedaspects; the circuitry and/or programming can be virtually anycombination of hardware, software, and/or firmware configured to effectthe herein-referenced aspects depending upon the design choices of thesystem designer. In addition to the foregoing, other aspects aredescribed in the claims, drawings, and text forming a part of thepresent application.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations and omissions of detail. Those skilledin the art will appreciate that the summary is illustrative only and isnot intended to be in any way limiting.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram representing an exemplary computing devicesuitable for use in conjunction with providing a system with which thewirelessly updated vehicle identification card can communicate andreceive updates;

FIG. 2 illustrates an exemplary networked computing environment of whichthe wirelessly updated vehicle identification card may be a part and inwhich many computerized processes may be implemented to provide updatesto the wirelessly updated vehicle identification card;

FIG. 3 is a diagram of an example system wherein proof of insurance cardtechniques may be implemented.

FIG. 4A illustrates a blown-up example vehicle identification card thatmay be utilized in the system of FIG. 3.

FIG. 4B illustrates a blown-up example webpage that may be generated bythe system of FIG. 3.

FIG. 5 illustrates an operational flow representing example operationsrelated to generating vehicle identification card including anadditional optional operation.

FIG. 6 illustrates an alternative embodiment of the operational flow ofFIG. 5.

FIG. 7 illustrates additional alternative embodiments of the operationalflow of FIG. 5.

FIG. 8 illustrates an alternative embodiment of the operational flow ofFIG. 5.

FIG. 9 illustrates an operational flow representing example operationsrelated to monitoring vehicle related transactions including additionaloptional operations.

FIG. 10 illustrates an additional alternative embodiment of the exampleoperational flow of FIG. 7.

FIG. 11 illustrates an operational flow representing example operationsrelated to authorizing vehicle based transactions including additionaloptional operations.

FIG. 12 illustrates an additional alternative embodiment of the exampleoperational flow of FIG. 11.

FIG. 13 illustrates an additional alternative embodiment of the exampleoperational flow of FIG. 11.

FIG. 14 illustrates an additional alternative embodiment of the exampleoperational flow of FIG. 11.

FIG. 15 is a front exterior view of an example wirelessly updatedvehicle identification card with a dynamic display;

FIG. 16 is a back exterior view of the example wirelessly updatedvehicle identification card with a dynamic display of FIG. 15;

FIG. 17 is an interior view of the example wirelessly updated vehicleidentification card of FIG. 15 showing an example configuration ofvarious high level components within the card;

FIG. 18 is an exploded perspective side view of the wirelessly updatedvehicle identification card of FIG. 15 along with a perspective sideview of a completed assembly of the card;

FIG. 19 is a diagram illustrating an example system in which thewirelessly updated vehicle identification card of FIG. 15 is updateddirectly via a long range wireless network;

FIG. 20 is a flow diagram illustrating an example operational process inwhich the wirelessly updated vehicle identification card of FIG. 15 isupdated utilizing a long range wireless network;

FIG. 21 is a flow diagram illustrating an example process in which thewirelessly updated vehicle identification card of FIG. 15 is updatedutilizing a mobile device;

FIG. 22 is a flow diagram illustrating an example operational process inwhich the wirelessly updated vehicle identification card of FIG. 15 isupdated utilizing a wireless network;

FIG. 23 is a flow diagram illustrating an example process in which thewirelessly updated vehicle identification card of FIG. 15 utilizesbiometric security features;

FIG. 24 is a flow diagram illustrating an example process in which thewirelessly updated vehicle identification card of FIG. 15 utilizesbiometric security features;

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Example ComputingDevices and Environment

Referring to FIG. 1, shown is a block diagram representing an exemplarycomputing device suitable for use in conjunction with providing a systemwith which a wirelessly updated vehicle identification card cancommunicate and receive updates. For example, the computer executableinstructions that carry out the processes and methods to communicateupdates to a wirelessly updated vehicle identification card may resideand/or be executed in such a computing environment as shown in FIG. 1.The computing system environment 220 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto the scope of use or functionality of the disclosed technology.Neither should the computing environment 220 be interpreted as havingany dependency or requirement relating to any one or combination ofcomponents illustrated in the exemplary operating environment 220.

Aspects of the disclosed technology are operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of well known computing systems, environments,and/or configurations that may be suitable for use with the disclosedtechnology include, but are not limited to, personal computers (PCs),server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set-top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

Aspects of the disclosed technology may be implemented in the generalcontext of computer-executable instructions, such as program modules,being executed by a computer. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data types.Aspects of the disclosed technology may also be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including memory storagedevices.

An exemplary system for implementing aspects of the disclosed technologyincludes a general purpose computing device in the form of a computer241. Components of computer 241 may include, but are not limited to, aprocessing unit 259, a system memory 222, and a system bus 221 thatcouples various system components including the system memory to theprocessing unit 259. The system bus 221 may be any of several types ofbus structures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. By wayof example, and not limitation, such architectures include IndustryStandard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA)local bus, the Peripheral Component Interconnect (PCI) bus also known asMezzanine bus, as well as its successor, the PCI-Express standard. Insome embodiments, the exemplary system may additionally include agraphics interface 231 that renders graphics, video memory 230 that canbe used to cache graphics, and a GPU 229 that executes the instructionsto render graphics.

Computer 241 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 241 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can accessed by computer 241. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, long andshort range radio frequency (RF), infrared, and other wireless media.Combinations of any of the above should also be included within thescope of computer readable media.

The system memory 222 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 223and random access memory (RAM) 260. A basic input/output system 224(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 241, such as during start-up, istypically stored in ROM 223. RAM 260 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 259. By way of example, and notlimitation, FIG. 1 illustrates operating system 225, applicationprograms 226, other program modules 227, and program data 228.

The computer 241 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 238 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 239that reads from or writes to a removable, nonvolatile magnetic disk 254,and an optical disk drive 240 that reads from or writes to a removable,nonvolatile optical disk 253 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 238 is typically connectedto the system bus 221 through an non-removable memory interface such asinterface 234, and magnetic disk drive 239 and optical disk drive 240are typically connected to the system bus 221 by a removable memoryinterface, such as interface 235.

The drives and their associated computer storage media discussed above,and illustrated in FIG. 1, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 241. In FIG. 1, for example, hard disk drive 238 is illustratedas storing operating system 258, application programs 257, other programmodules 256, and program data 255. Note that these components can eitherbe the same as or different from operating system 225, applicationprograms 226, other program modules 227, and program data 228. Operatingsystem 258, application programs 257, other program modules 256, andprogram data 255 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 241 through input devices such as akeyboard 251 and pointing device 252, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit259 through a user input interface 236 that is coupled to the systembus, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB). A monitor242 or other type of display device is also connected to the system bus221 via an interface, such as an insecure or secure video interface 232.An exemplary secure video standard would be the High-DefinitionMultimedia Interface (HDMI) standard. In addition to the monitor,computers may also include other peripheral output devices such asspeakers 244 and printer 243, which may be connected through a outputperipheral interface 233.

The computer 241 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer246. The remote computer 246 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 241, although only a memory storage device 247 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 245 and a wide area network (WAN)249, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 241 is connectedto the LAN 245 through a network interface or adapter 237. When used ina WAN networking environment, the computer 241 typically includes amodem 250 or other means for establishing communications over the WAN249, such as the Internet. The modem 250, which may be internal orexternal, may be connected to the system bus 221 via the user inputinterface 236, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 241, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 248 as residing on memory device 247. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

It should be understood that the various techniques described herein maybe implemented in connection with hardware or software or, whereappropriate, with a combination of both. Thus, the methods and apparatusof the disclosure, or certain aspects or portions thereof, may take theform of program code (i.e., instructions) embodied in tangible media,such as floppy diskettes, CD-ROMs, hard drives, or any othermachine-readable storage medium wherein, when the program code is loadedinto and executed by a machine, such as a computer, the machine becomesan apparatus for practicing the disclosure. In the case of program codeexecution on programmable computers, the computing device generallyincludes a processor, a storage medium readable by the processor(including volatile and non-volatile memory and/or storage elements), atleast one input device, and at least one output device. One or moreprograms that may implement or utilize the processes described inconnection with the disclosed technology, e.g., through the use of anAPI, reusable controls, or the like. Such programs are preferablyimplemented in a high level procedural or object oriented programminglanguage to communicate with a computer system. However, the program(s)can be implemented in assembly or machine language, if desired. In anycase, the language may be a compiled or interpreted language, andcombined with hardware implementations.

Although exemplary embodiments may refer to utilizing aspects of thedisclosure in the context of one or more stand-alone computer systems,the disclosure is not so limited, but rather may be implemented inconnection with any computing environment, such as a network ordistributed computing environment. Still further, aspects of thedisclosure may be implemented in or across a plurality of processingchips or devices, and storage may similarly be effected across aplurality of devices. Such devices might include personal computers,network servers, handheld devices, supercomputers, or computersintegrated into other systems such as automobiles and airplanes.

In light of the diverse computing environments that may be builtaccording to the general framework provided in FIG. 1, the systems andmethods provided herein cannot be construed as limited in any way to aparticular computing architecture. Instead, the invention should not belimited to any single embodiment, but rather should be construed inbreadth and scope in accordance with the appended claims.

Referring next to FIG. 2, shown is an exemplary networked computingenvironment of which the wirelessly updated vehicle identification cardmay be a part of, and in which many computerized processes may beimplemented to provide updates to the wirelessly updated vehicleidentification card. For example, object 273 may represent a wirelesslyupdated vehicle identification card as one of the various clients on thenetwork of FIG. 2 using and/or implementing systems that provide themeans of communication between various clients and servers on thenetwork. In this regard, any computer system or environment having anynumber of processing, memory, or storage units, and any number ofapplications and processes occurring simultaneously, is consideredsuitable for use in connection with the systems and methods provided.

Distributed computing provides sharing of computer resources andservices by exchange between computing devices and systems. Theseresources and services include the exchange of information, cachestorage and disk storage for files. Distributed computing takesadvantage of network connectivity, allowing clients to leverage theircollective power to benefit the entire enterprise. In this regard, avariety of devices may have applications, objects or resources that mayimplicate the processes described herein.

FIG. 2 provides a schematic diagram of an exemplary networked ordistributed computing environment. The environment comprises computingdevices 271, 272, 276, and 277 as well as objects 273, 274, and 275, anddatabase 278. Each of these entities 271, 272, 273, 274, 275, 276, 277and 278 may comprise or make use of programs, methods, data stores,programmable logic, etc. The entities 271, 272, 273, 274, 275, 276, 277and 278 may span portions of the same or different devices such as PDAs,audio/video devices, music players, personal computers, etc. Each entity271, 272, 273, 274, 275, 276, 277 and 278 can communicate with anotherentity 271, 272, 273, 274, 275, 276, 277 and 278 by way of thecommunications network 270. In this regard, any entity may beresponsible for the maintenance and updating of a database 278 or otherstorage element.

This network 270 may itself comprise other computing entities thatprovide services to the system of FIG. 2, and may itself representmultiple interconnected networks. In accordance with an aspect of thedisclosure, each entity 271, 272, 273, 274, 275, 276, 277 and 278 maycontain discrete functional program modules that might make use of anAPI, or other object, software, firmware and/or hardware, to requestservices of one or more of the other entities 271, 272, 273, 274, 275,276, 277 and 278.

It can also be appreciated that an object, such as 275, may be hosted onanother computing device 276. Thus, although the physical environmentdepicted may show the connected devices as computers, such illustrationis merely exemplary and the physical environment may alternatively bedepicted or described comprising various digital devices such as PDAs,televisions, MP3 players, etc., software objects such as interfaces, COMobjects and the like.

There are a variety of systems, components, and network configurationsthat support distributed computing environments. For example, computingsystems may be connected together by wired or wireless systems, by localnetworks or widely distributed networks. Currently, many networks arecoupled to the Internet, which provides an infrastructure for widelydistributed computing and encompasses many different networks. Any suchinfrastructures, whether coupled to the Internet or not, may be used inconjunction with the systems and methods provided.

A network infrastructure may enable a host of network topologies such asclient/server, peer-to-peer, or hybrid architectures. The “client” is amember of a class or group that uses the services of another class orgroup to which it is not related. In computing, a client is a process,i.e., roughly a set of instructions or tasks, that requests a serviceprovided by another program. The client process utilizes the requestedservice without having to “know” any working details about the otherprogram or the service itself. In a client/server architecture,particularly a networked system, a client is usually a computer thataccesses shared network resources provided by another computer, e.g., aserver. In the example of FIG. 2, any entity 271, 272, 273, 274, 275,276, 277 and 278 can be considered a client, a server, or both,depending on the circumstances.

A server is typically, though not necessarily, a remote computer systemaccessible over a remote or local network, such as the Internet. Theclient process may be active in a first computer system, and the serverprocess may be active in a second computer system, communicating withone another over a communications medium, thus providing distributedfunctionality and allowing multiple clients to take advantage of theinformation-gathering capabilities of the server. Any software objectsmay be distributed across multiple computing devices or objects.

Client(s) and server(s) communicate with one another utilizing thefunctionality provided by protocol layer(s). For example, HyperTextTransfer Protocol (HTTP) is a common protocol that is used inconjunction with the World Wide Web (WWW), or “the Web.” Typically, acomputer network address such as an Internet Protocol (IP) address orother reference such as a Universal Resource Locator (URL) can be usedto identify the server or client computers to each other. The networkaddress can be referred to as a URL address. Communication can beprovided over a communications medium, e.g., client(s) and server(s) maybe coupled to one another via TCP/IP connection(s) for high-capacitycommunication.

In light of the diverse computing environments that may be builtaccording to the general framework provided in FIG. 2 and the furtherdiversification that can occur in computing in a network environmentsuch as that of FIG. 2, the systems and methods provided herein cannotbe construed as limited in any way to a particular computingarchitecture or operating system. Instead, the disclosure should not belimited to any single embodiment, but rather should be construed inbreadth and scope in accordance with the appended claims.

Proof of Insurance Vehicle Identification Card

In various embodiments of the present disclosure, a proof of insurancecredit card solution is described wherein the features of a vehicleidentification card are further combined with the advantages of displayand wireless updating capabilities as defined further below. In someembodiments, qualifying members purchasing a new vehicle can enroll in aproof of insurance credit card program. In one such embodiment, themember receives a credit card that is issued to the VIN number of thepurchased vehicle and can thus be used to make purchases and to provideproof of insurance. This integration of services provides uniquebusiness opportunities to the issuer of the card.

In various embodiments, the credit card portion of the proof ofinsurance vehicle identification card may be integrated with a separatefund that can be tapped into in order to pay for repairs or otherexpenses related to the vehicle or in the event of an accident or otherclaim such as burglary or non-accident related damage (e.g., vandalism).This secured fund can be controlled by the provider, thus allowing theprovider to earmark money for certain repairs or expenses, or forcertain companies to perform the repairs. Additionally, the provider ofthe vehicle identification card is in a position to monitor credittransactions of the insured and is able to provide them with informationrelated to the transactions, the vehicle, or rewards for taking care oftheir vehicle.

The provider is also in a position to integrate services and provide amember with one web page that includes information from multiplesources. The provider can create a web page that allows users to receiveinformation about their insurance policy, their credit transactions,rewards they may have earned, and vehicle based notifications.

FIG. 3 is a block diagram of an example system in which aspects of thepresent disclosure may be embodied. FIG. 4A and FIG. 4B depict anexample vehicle identification card and an example document that may betransmitted to the insured via the internet or mail. FIG. 3, FIG. 4A,and FIG. 4B are described in more detail below within the context of theoperations described in FIGS. 5-14. Additionally, those skilled in theart will note that some elements depicted in the block diagram areindicated in dashed lines, which in general, and throughout thedisclosure, is indicative of the fact that they are considered optional.

At a high level of abstraction, FIG. 3 depicts one or more users 101-2through 101-N where N is an integer greater than 1 associated with theirpersonal computers. FIG. 3 shows an user 101 who may have a personalcomputer 102 connected to a network such as the internet. The user 101may own a vehicle 120 that is insured by a provider 150.

The provider may include a web server 156 connected to the internet viaa network connection. The web server may have access to a database 155of user accounts via a database management module 151. The provider 150may optionally include a credit processing module 130 that is configuredto handle credit card transactions, or the provider 150 may optionallybe connected to a credit card company 160 or other entity that includesa credit card processing module 130.

The user 101 may make purchases with their vehicle identification card100 at one or more companies 140-1 through 104-N where N is an integergreater than 1. Each company 140-1 . . . 140-N may include a creditprocessing module 142 that allows each company to authorize credittransactions. The provider 150 may also employ agents 101-A and providethe agents with terminals 102. The agents may submit requests to thedatabase 155 via the network for information such as the user's account.The agents may then provide services for the user 101.

FIG. 4A illustrates an embodiment of a vehicle identification card 200of the present disclosure. The embodiment of vehicle identification card200 illustrates a first and a second side 200A and 200B respectively. Invarious embodiments, the vehicle identification card 200 may be issuedby the provider 150. The example vehicle identification card 200includes a proof of insurance statement 202 that allows the card to bepresented as proof of insurance, the VIN number 205 of the vehicle inwhich the card is associated, the expiration date of the card 206,account information 201 and a magnetic strip 203 that is encoded withaccount information.

FIG. 4B depicts an example document that may be embedded in a web page210 generated by the system or printed and sent to the user 101 of thevehicle identification card 100. The web page 210 may includeinformation about credit transactions 207, vehicle service reminders206, and vehicle related notifications such as a recall notice 208.

One skilled in the art will recognize that the operations illustrated inFIGS. 5-14 are examples and other embodiments exist. Those skilled inthe art will note that some operations in FIG. 5-14 are indicated bydashed lines, which, in general, indicates that they are to beconsidered optional. More specifically, different implementations willtypically employ one of more herein-described operations dependent uponcontext, and the selection of the appropriate operations(s) appropriateto the various context(s) is within the skill of one in the art in lightof the teachings herein.

FIG. 5 depicts the example operational flow 300 including an additionaloperation 406. Operation 300 begins the operational process, typicallyat a provider 150 pursuant to enrolling user 101 into an insurancepolicy. Operation 302 illustrates providing a vehicle identificationcard with proof of automotive insurance information. For example, asdepicted in FIG. 3, provider 150 issues a vehicle identification card100 that includes proof of automotive insurance information 102. Theexample card 100 of FIG. 3 may have the look and feel of a banking cardsuch as an ATM card, credit card, debit card or any other type of card.The card 100 of FIG. 3 may include proof of automotive insuranceinformation 102. The information may contain a POI (proof of insurance)notification including, for example, a proof of liability disclaimerthat establishes the card as a valid proof of liability insurance for avehicle. While a notification including a disclaimer is disclosed, oneskilled in the art will appreciate that a POI notification may includeany type of identifying information that an insured person can presentto a third party to prove they have valid insurance issued by aninsurance company. A more specific example vehicle identification cardthat includes proof of automotive insurance information is depicted bythe card 200 of FIG. 4A.

Operation 304 illustrates providing the vehicle identification card withcharge account information. For example, provider 150 can issue avehicle identification card 100 that may include charge accountinformation 104. The charge account information 104 can be encodedwithin the vehicle identification card so that the user 101 can use thevehicle identification card like a credit card. The vehicleidentification card in some embodiments can be similar to the card 200of FIG. 4A. The card 200 may include, for example, a number located onthe card 201, data stored in a computer chip (not shown) or a magneticstrip on the card 203.

Additionally or alternately, the operational flow 300 may includeexample operation 406 that illustrates charge account information thatis valid for the length of an automotive insurance policy. For example,provider 150 may issue a vehicle identification card 100 that can beutilized as a credit card. The credit card portion of the card may onlybe valid for the length of an insurance contract associated with avehicle 120. As depicted more explicitly by the example card in FIG. 4A,the expiration date 206 of the card 200 is desirably the same as thelength of an insurance policy covering a vehicle 120, but in otherexample embodiments, the expiration date can be set to expire at a dateprior to the term of the insurance policy or after the term of theinsurance policy.

FIG. 6 depicts the example operational flow 300 including an additionaloperation 508. Operation 508 depicts providing charge accountinformation that includes credit card information issued by a creditprovider as another additional example embodiment of the operationalflow 300 of FIG. 5. For example, a provider 150 may generate a vehicleidentification card 100 that includes account information 104 that isassociated with a credit processing company 160 such as VISA® orAmerican Express®. The account information 104 allows the vehicleidentification card 100 to be used as a credit card in a credit basedtransaction.

FIG. 7 depicts the example operational flow 300 including multipleadditional operations. In some embodiments, the operational flow 300 mayinclude operations 610, 712, and 814. In operations that includeoperation 610, a provider 150 may create a vehicle identification card100 that includes information about a specific vehicle 120 covered bythe proof of insurance such as the make and model of the vehicle, or anyother type of information related to the vehicle.

In embodiments of the operational flow 300 that include operation 712the information integrated with the vehicle identification card 100 mayinclude information about the specific vehicle 120 such as the vehicleidentification number, or VIN number 103 of the vehicle 120 covered byan insurance contract. A more detailed example of the information thatmay be integrated into a vehicle identification card is depicted by theexample card of FIG. 4A.

Furthermore, in embodiments of the operational flow 300 that includeoperation 814 the vehicle identification card 100 of FIG. 3 may beissued to the vehicle 120. For security purposes, having the vehicleidentification card 100 issued to the VIN number 103 of the vehicle 120assures a company 140-1 working on the vehicle 120 that the vehicleidentification card 100 is not stolen because the fact that the VINnumber of the card 103 is same as the VIN number of the vehicle 120. Forexample, an automotive repair shop may perform work on a vehicle 120.When a user 101 presents the vehicle identification card 100 as paymentfor any services performed the repair shop may compare the VIN number103 of the vehicle identification card 100 to the VIN number of thevehicle 120 in order to determine whether to accept the card as payment.A specific example of issuing a vehicle identification card to the VINnumber of a vehicle is depicted in FIG. 2A. For example, the card 200may not include the name of the user 101, but only the VIN number 205 ofthe vehicle that it is associated with.

FIG. 8 depicts another embodiment of the example operational flow 300including another optional operation 916. Operation 916 of FIG. 8illustrates providing the vehicle identification card with informationabout an insurance policy issued to said vehicle. For example, insuranceprovider 150 of FIG. 3 provides a vehicle identification card 100including an insurance policy covering the vehicle 120.

FIG. 9 illustrates example operations related to monitoring vehiclerelated transactions including operations 1000-1006 and additionaloptional operations.

Operation 1000 begins the operational process, typically such a processbegins after a user 101 is issued a vehicle identification card 100 andbegins to purchase services and items with the vehicle identificationcard 100. Operation 1002 illustrates monitoring transactions related toa vehicle identified by a vehicle identification card. For example,credit processing module 130 that may be either maintained by aninsurance provider 150, or a credit card company 160 may monitor, e.g.,receive one or more packets of information over a network connection 152from one or more companies 140-1 through 140-N, that indicate that acredit transaction was performed. The database management module 151 maythen determine whether the transaction was for a vehicle 120 (or relatedexpense) identified by the vehicle identification card 100, e.g., thesoftware may check each transaction by a user 101 to see if it was at agas station, or at a oil changing shop.

Operation 1004 illustrates utilizing transaction information related tosaid vehicle to generate vehicle based notifications. For example,database management module 151 may determine that at least one credittransaction was related to the vehicle 120 by comparing the VIN number103 of the vehicle identification card stored in a user accountmaintained by a database to the VIN number 103 of the car 120 identifiedby the vehicle identification card 100 and the module 151 may generateone or more packets of information including a notification for the user101. The notification may be to notify the user 101 that they receivedrewards for making the purchase, or any type of notification.

Operation 1006 illustrates storing said notifications in a storagedevice associated with an account. For example, database managementmodule 151 may store the notification generated by operation 1004 in adatabase 155 managed by the provider 150. The database 155 may beaccessed by a web server 156 in order to generate, in response to a httprequest from personal computer 102, a web page 210 such as the web pageshown by FIG. 4B that includes a list of prior credit card transactions207 and a list of vehicle related notifications such as the examplevehicle related notifications displayed in the service reminder section206 of webpage 210.

As depicted by FIG. 9, in various embodiments of the operationalprocedure 1000 the procedure may include operation 1108. In embodimentsthat include the optional operation 1210, the database management module151 may receive one or more packets of information indicative of anelectronic advertisement from one or more companies 140-1 through 140-N.The companies 140-1 through 140-N may have performed a service for thevehicle 120, or may be soliciting vehicle related work from the user101. A web server 156 may process such requests and store suchadvertisements in a database 155 so that if the user 101 requests accessto their account the web server 156 may generate code operable to rendera webpage that includes a list of credit card transactions and targetedadvertisements.

As depicted by FIG. 9, in various embodiments of the operationalprocedure 1000 the procedure may include operation 1210. In embodimentsthat include operation 1210, the database management module 151 maydetermine that at least one credit transaction was for, or related to,the vehicle 120 and generate an incentive for the user 101. Theincentive may be a reward, e.g., a coupon, a rebate, a discount, or anyother type of incentive to give the user 101 an additional reason totake care of their vehicle.

As depicted by FIG. 9 the operational procedure 1000 may includeoperation 1212. In embodiments that include such an operation, thedatabase management module 151 in one embodiment may generate one ormore reminders for the user 101 to perform a vehicle related act in thefuture such as a reminder to change their vehicle's oil in 3 months.

As depicted by FIG. 9 the operational procedure 1000 may includeoperation 1214. In embodiments that include such an operation, thedatabase management module 151 may identify vehicle related transactionsfor the vehicle 120 and generate a vehicle history report for thevehicle 120.

As further depicted by the operational operation 1316, once the databasemanagement module 151 has generated a vehicle history report, in someembodiments, the web server 156 may distribute the report in response toa request via a network connection 152 from a user 101 that indicatesthat the user 101 wants to allow other users 101-2 through 101-N toaccess the vehicle history report. The web server 156 may, for example,transmit the vehicle history report to a recipient via an email, or theweb server may transmit html code operable to generate a vehicle historyon the user's personal computer 102.

FIG. 10 depicts the example operational flow 100 including an additionaloperation 1408. Operation 1408 illustrates receiving vehicle noticesfrom an entity and generating one or more vehicle relatedrecommendations. For example, database management module 151 may receiveone or more packets of information indicative of a notification from anentity such as a company 140-1 through 140-N that performed a service onor for the vehicle 120, or manufactured parts that are in the vehicle120. The database management module 151 may then generate vehiclerelated recommendations such as a recommendation to replace a part dueto a factory recall of the part. An example of such a notification isdepicted by the recall notice area 208 of the example document 210 ofFIG. 4B.

FIG. 11 illustrates example operations related to authorizing vehiclebased transactions including operations 1500-1504 and additionalalternative operations.

Operation 1500 begins the operational procedure, typically after theprovider 150 has issued a vehicle identification card 100 to a user 101and the user 101 utilizes the vehicle identification card to purchaseitems or services. Operation 1502 illustrates maintaining a database ofaccounts, each account associated with a vehicle, said accountsincluding credit information and secured available credit information.For example, database 155 of provider 150 may include multiple accounts,and each account may include information related to a vehicle 120 theprovider insures, a credit limit of the user 101, and the securedavailable credit of the user 101. The secured available credit, or SAC,can be an amount of credit stored in the account of the user 101. Theamount of credit may have previously been deposited into the account byan agent 101-A who works for the provider 150, or it may deposited bythe user 101. In one example embodiment, the SAC may be used to increasethe credit limit of the user 101 in order for credit transactionsgreater than the credit limit of the user 101 to be approved, e.g., thecredit limit of the user 101 is temporarily increased from $500 to $2000in order for a certain transaction to be approved.

In other embodiments the SAC may be a separate fund that can be utilizedby the credit processing module 130 to approve transactions undercertain circumstances. In this embodiment the user 101 may have twoseparate funds in their account, the funds may be thought of as separatepools of credit in the same account or separate credit sub-accounts inan account. One skilled in the art will appreciate that there aremultiple ways to separate pools of credit and that the disclosedembodiments are not limited to any specific way of distinguishingbetween two different funds.

Operation 1504 illustrates determining whether secured available creditis available and authorizing the transaction. For example, creditprocessing module 130 of provider 150 may receive a request to approve avehicle related transaction. In one example situation, the amount of thevehicle related transaction may be more than the approved credit limitof a user 101. In one embodiment the user 101, or agent 101-A may havepreviously released SAC to increase the credit limit of the user 101.Thus, when the credit processing module 130 checks the credit limit ofthe user 101 it will determine that the user's limit is adequate for thetransaction and approve the transaction.

In another example embodiment, the SAC may be a separate fund. Inresponse to receiving a request to approve the transaction, the creditprocessing module 130 may invoke the database management module 151 todetermine whether there is any SAC available that can be to approve thetransaction. In this example, the credit processing terminal 142 locatedat a business 140-1 may receive the card, e.g., the card is swiped andthe information is read out from the card and a prompt is provided(e.g., displayed) asking which fund should be used to process thetransaction. The prompt may be, for example, a screen rendered on thecredit processing terminal 142 requesting that a user 101 press 1 for acredit transaction, or 2 for a secured SAC transaction. The prompt mayrequest that a user 101 input a SAC pin, such as a 4 digit number thatthe user 101 knows, or the prompt may request that a user 101 input aone-time-usable pin for the specific transaction that was given to theuser 101 from an insurance agent 101-A. The agent 101-A may have giventhe pin to the user 101 via a phone conversation, an email, a textmessage, etc.

As depicted by FIG. 11, the example operational flow 1500 may includethe additional operation 1606 that illustrates determining whethersecured available credit is available for a specific service performedfor said vehicle. For example, credit processing module 130 of provider150 may receive a request to approve a vehicle related transaction overa network connection 152. The credit processing module 130 may invoke adatabase management module 151 that may check the account of the user101 associated with the vehicle identification card 100 to determinewhether funds have been approved for the specific service performed and,if the funds were approved the credit processing module 130 may approvethe transaction. The credit transaction may indicate, for example, thatthe transaction was an SAC transaction and that the transaction is for aspecific service performed for or on the vehicle 120, e.g., thewindshield wipers were changed, the rear bumper was fixed, or any othertype of service that could be performed on or for a vehicle 120.

FIG. 11 depicts additional embodiments of the operational procedure 1500that include operations 1606 and 1608. In operational flows that includeone or both of theses example operations, the credit processing module130 of the provider 150 may receive a request to approve a vehiclerelated transaction over a network connection 152. In one embodiment,the database management software 151 may check to see if SAC has beenearmarked for a specific company 140-1 to perform work on the vehicle.If SAC has been earmarked for a particular company 140-1 to perform thework and the request is from the company 140-1 the credit limit of theuser 101 may be increased for the transaction in order for thetransaction to be approved.

FIG. 11 additionally depicts the example operational flow 1500 includingthe example operation 1710 that illustrates receiving a request toapprove a transaction, and determining whether the transaction is acredit based transaction or a secured available credit basedtransaction. For example, credit processing module 130 of provider 150may receive a request to approve a transaction via a network connection152 and the credit processing module 130 may determine whether thetransaction is a typical credit card type of transaction, or if thetransaction is a secured available credit type of transaction.

FIG. 12 and FIG. 13 depict the example operational flow 1500 includingoperation 1812 (FIG. 12) and operation 1914 (FIG. 13). In exampleoperational flows that include one or both of the example operations1812 and 1914, a network connection 152 of web server 156 may receiveone or more packets of information indicative of a request to authorizea transaction utilizing SAC from a user's computer system 102 and inresponse the web server may generate html operable to render a web pageon the user's client 102. The webpage may include one or more fields ofinformation similar to that of FIG. 4B and at least one dialog box thatis configured to receive requests from a user 101 to authorize a SACbased transaction. The transaction may have been temporarily approved atthe point of sale. The user 101 may then drive the vehicle 120 (testingto see if the repairs truly were performed correctly) and the user 101may later access their account via the internet and approve thetransaction. Once the transaction has been approved by the user 101, therepair shop may receive an approval code for the transaction, or atransfer of funds from the user's account to the company's account mayoccur. Alternatively or additionally, the request to authorize atransaction may originate from an insurance adjuster's terminal 102-A.The insurance adjustor may have previously released SAC.

FIG. 14 depicts the example operational flow 1500 including additionaloperation 2016. Operation 2016 illustrates receiving accidentinformation related to said specific vehicle; determining securedavailable credit usable for an accident related transaction; and storingsaid secured available credit in a storage device associated with saidaccount. For example, insurance adjuster terminal 102-A may receiveinformation related to an accident involving a specific vehicle 120owned by a user 101. The information may be processed by the terminal102-A and an amount of SAC may be determined based on the make and modelof the vehicle 120, the type and amount of damage to the vehicle 120,and how much the vehicle 120 was worth before the accident. The SAC maythen be stored in a database 155 associated with the account of the user101. The SAC may then be utilized to pay for repairs to the vehicle 120.

The foregoing detailed description has set forth various embodiments ofthe systems and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and/or operationwithin such block diagrams, flowcharts, or examples can be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or virtually any combination thereof.

Wirelessly Updated VIN Card with Display

In one embodiment of the present disclosure, a wireless updated VIN cardincorporating one or more of the characteristics described above isdisclosed. FIG. 15 illustrates a front exterior view of an examplewirelessly updated VIN card 1500 with one or more displays. In thisexample embodiment, the card 1500 may include one or more displays 3001,3002, 3003, and or 3005 that can be activated and display the availablebalance of the card 3001, a card account number 3003, the card holder'sname 3005, and/or card's expiration date 3002. Additionally, one skilledin the art will appreciate that the entire front panel of the card maybe a display, and the example card disclosed is not a limiting example.In addition to the one or more displays, the card 3000 may include abiometric input area (e.g., thumbprint reader) 3007, an area for thebank or financial institution's name and/or logo 3008, and an area forthe credit card network name and/or logo 3009 (which is often aholographic image). The card 3000 may be approximately the size of astandard sized credit card. For example, the ID-1 format of theInternational Organization for Standardization (ISO) 7810 specifies asize of 85.60×53.98 mm (3.370×2.125 in) with a thickness of 0.76 mm andcorners rounded with a radius of 3.18 mm. This size is commonly used forbanking cards (ATM cards, credit cards, debit cards, etc.) and issuitable for the example wirelessly updated vehicle identification cardwith a dynamic display described herein. However, other sizes andstandards for identification or banking cards may also be suitable.

As illustrated in FIG. 15, the one or more displays, 3001, 3002, 3003,and/or 3005 may be any thin film display that is able to be integratedwith a vehicle identification card 3000 of the approximate sizedescribed above. For example, aspects of the present disclosure mayutilize displays that comprise a thin, flexible display, such as alight-emitting polymer (LEP) display for displaying information denotingaccount information, and/or other information. The LEP display maycover, for example, a portion of the surface of the card 3000, i.e.,section 3001, section 3003, etc., or one display may cover the wholesurface of at least one side of the card 3000 (not shown). Also, thedisplay may be touch-sensitive, e.g., it may provide the user with anumber of graphical images which enable the user to selectively chose acard feature by touching selected parts of the touch-sensitive display.

The card can include a microprocessing unit (MPU) for executinginstructions stored in a memory, a liquid crystal display (LCD), coupledto the MPU for displaying information, a keypad coupled to the MPU andto the display for entering data by the user, an interface fortransferring signals between the card and an external system such as acard reader, a point of sale terminal (POS) terminal, or an automatedteller machine when the smart card is in short range of the externalsystem. The card can include photovoltaic cells for providing power tothe card when the card is exposed to light.

FIG. 16 depicts a back exterior view of the example wirelessly updatedvehicle identification card with a dynamic display of FIG. 15. Shown isa credit card magnetic strip area 3101, a card holder signature area3103 that may in some embodiments be contained within a display andinclude a digital image of the user's signature, and a cardmicroprocessor processing device 3104.

FIG. 17 depicts an interior view of the example wirelessly updatedvehicle identification card of FIG. 15 showing an example configurationof various high level components within the card. Shown is amicroprocessor 3104, a RF transceiver 3201, an integrated antenna 3209,a memory module 3203, a biometric input module 3205, a thin battery 3207connected to an energy supply such as a photovoltaic cell 3211, anexample display 3001, and a system bus 3213 communicatively connectingthese major components.

The thin battery 3207 is that which provides enough power to operate theother individual components within the card, such as batteries availablefrom Thin Battery Technologies, Inc. located in Parma, Ohio. Examplebattery specifications are as follows: Thickness<0.4 mm, Voltage>2Volts, Size 2.2×2.9 cm², rechargeable<3 mn, energy: 20 mAh. However,variations from these specifications are also possible.

The biometric input area 3205 is an area that reads biometricidentification data. This may be, for example, a thumb or fingerprintreader, voiceprint reader (using a built-in microphone), or facialfeature data reader (using a built-in camera). The thumbprint reader maybe, for example a silicon integrated sensor device such as thoseavailable from AuthenTec, Inc., located in Melbourne, Fla.

In some embodiments of the present disclosure, the RF transceiver 3201can send and receive long range RF signals such as cellular telephonesignals. A suitable transceiver may be included in a RF transceiverintegrated circuit chip such as the BCM2085 65-nm CMOS DigRF EDGECellular Transceiver, available from Broadcom Corporation located inIrvine, Calif. This example transceiver chip is a 65-nm CMOS single chipquad-band GSM/GPRS/EDGE RF transceiver for GSM850/EGSM900/DCS1800/PCS1900 voice and data applications. In other embodiments, the RFtransceiver may include a Bluetooth transceiver, a 802.XX transmittersuch as a WiMAX transceiver or a WiFi transceiver, or an active orpassive RFID tag. Other suitable transceivers may include, but are notlimited to, any transceiver that has wireless capabilities and a smallform factor.

The antenna 3209 is embedded within the card 3000 and is operativelyconnected to the RF transceiver 3201. The antenna 3209 may be loopedaround the perimeter of the card and/or across the card 3000 if theantenna 3209 is located on a different plane within the card 3000 thanthe other components for isolation purposes. In at least one embodiment,the antenna 3209 may be an Isolated Magnetic Dipole™ (IMD) internalcellular antenna.

FIG. 18 depicts an exploded perspective side view of the wirelesslyupdated vehicle identification card of FIG. 15, along with a perspectiveside view of a completed assembly of the card. Shown are four examplelayers. However, the number and type of layers may vary depending on thenumber and type of particular internal components included within thecard 3000. The top layer is the Antenna-Display-Biometric input layer3301. Next, coupled to the Antenna-Display-Biometric input (e.g.fingerprint) layer 3301 is the Digital Processor-Memory layer 3303.Coupled to the Digital Processor-Memory layer 3303 is the Battery-EnergyScavenging layer 3305. Finally, coupled to the Battery-Energy Scavenginglayer 3305 is the Substrate Shield layer 3307. These layers all coupledtogether (with the substrate shield layer being an outside layer) form aunified thin film card assembly 3000.

FIG. 19 illustrates an example system wherein aspects of the presentdisclosure may be embodied. The example system of FIG. 19 is describedin more detail below with respect to how the elements depictedinterrelate with the operational procedures illustrated in the flowcharts FIG. 20 through FIG. 24. One skilled in the art will note thatthe example elements depicted in FIG. 19 are provided to illustrate anoperational context to practice aspects of the present disclosure. Thus,the example operational context is to be treated as illustrative onlyand in no way limits the scope of the claims. Furthermore, those skilledin the art will note that some elements depicted in FIG. 19 areindicated in dashed lines, which in general, and throughout thedisclosure, is indicative of the fact that they are considered optionaland/or they are considered to be optionally located at their positionwithin their respective figure.

Generally speaking, the exemplary system includes an insuranceinstitution 7001, that can include, or have access to, one or moredatabases of information that contain one or more customer accounts. Theone or more databases of information can be coupled to a databasemanagement program that can perform complex operations to control theorganization, storage, and retrieval of data in the databases. Thesystem of FIG. 19 additionally includes a card 3000 similar to thatdescribed above that has an RF module 3201 and one or more displays 3001and/or 3003, for example. Additionally, the card 3000 includes, in someembodiments, a biometric reader 3007. As shown in FIG. 19, the RF module3201 of the card 3000 can, in some embodiments, be in wirelesscommunication with a long range wireless tower 7010 that iselectronically coupled to a long range wireless service provider 7015,i.e., a provider of long range wireless signals such as signals in thecellular frequency band. In additional, or alternative embodiments ofthe present disclosure, and described in more detail below, the longrange signal tower 7010 may be in wireless communication with a user'scellular phone 7012. In these, and other embodiments, the cellular phone7012 may be in wireless communication with the RF module 3201 of thecard 3000. In this situation, the long range signal tower 7010 maytransmit information to the cellular phone 7012, and the cellular phonemay transmit the same, or additional information to the RF module 3201using a cellular signal or a short range RF signal such as Bluetooth orRFID. FIG. 17 additionally depicts a close proximity RF system such asthe router 7020 of FIG. 17. The router 7020 may include, but is notlimited to, one or more hardware modules that include circuitry forenabling the router 7020 to communicate utilizing an 802 protocol suchas 802.11 (WiFi) or 802.16 (WiMAX).

FIG. 20 illustrates an example operational flow chart 8000 that depictsaspects of the present disclosure. Operation 8001 illustrates updatingan insurance institution's database with information related to a useraccount. These updates may be made, for example, by utilizing point ofsale transaction terminals that are currently in use in most retailstores that handle credit/debit transactions. Or, in the same, oranother embodiment, the update may be some other activity that affectsthe balance of an account, i.e., the update may be a deposit or otherpayments made. A specific example of how a point of sale terminal isutilized in aspects of the present disclosure may include one or morecredit card readers that can access the account information storedwithin the card when the user makes a purchase. Information related tothe transaction can then be sent through one or more networks to theissuer of the card, or to a processing center that is configured toauthorize credit/debit transactions for one or more financialinstitutions. The database may include one or more programs, or modules,for determining when to authorize charges to the account and one ofthese programs or modules may be invoked to determine whether or not toauthorize or deny the transaction. In the event that the transaction isauthorized, the financial institution 7001 may then transmit anauthorization message back through the network to the (POS) terminal anda receipt can be printed for the user. In accordance with at least oneembodiment of the present disclosure, one or more programs or modulesmay monitor transaction activity of the user's account, and update theuser's account to reflect the transaction, i.e., in a debit cardscenario, the account of the user may be debited, and in a credit cardscenario the available balance of the card may be updated.

As illustrated by operation 8003, in this example embodiment, after theuser account is updated with information related to the transaction, theinsurance institution 7001 can transmit a signal indicative of theaccount information to the cellular service provider 7015. For example,the financial institution 7001 may be affiliated with one or morecellular providers and the financial institution 7001 can transmit oneor more packets of information indicative of the balance in a user'saccount to the cellular provider's network operations center. A specificexample of what information can be transmitted may include sending asignal that identifies that the transaction has taken place, i.e., if auser with an account balance of $1000.00 makes a purchase of $600.00with their VIN card, once the user's account in the database is updatedwith information indicative of the transaction, a signal indicative ofthe new balance, in this example $400.00, can be transmitted to thecellular tower 7010. Another specific example may include, but is notlimited to, an insurance institution 7001 transmitting a signalindicative of the current transaction instead of the resulting balanceto the cellular tower 7010. In this embodiment, the card 3000 maycontain a record of the user's transactions, and the card 3000 may usean adding/subtracting function of the CPU of the card 3000 to modify thetransaction record stored within the card 3000 to obtain the account'scurrent balance. While two different specific examples of operation 8003are disclosed, one skilled in the art will appreciate that these areexemplary and that other types of information may be transmitted inoperation 8003.

Once the long range signal service provider 7015 receives the accountinformation, it can be transmitted to the card as illustrated byoperation 8005. The account information (possibly encrypted) can be sentto address of the card 3000. For example, the card 3000 may includeinformation that identifies it to the wireless network it is incommunication with. In the example where the wireless network is acellular network, the card 3000 may have been previously assigned anumber by the long range signal provider 7015 that is stored in adatabase along with an association relating it to the number to theaccount of the user maintained by the financial provider, i.e., adatabase table may associate account “1234 1234 1234 1234” to phonenumber “555-555-5555.” In some embodiments, once the account informationis received by the long range signal service provider 7015, it maywirelessly transmit the information to the card 3000 as depicted byoperation 8007. In this situation, the long range signal serviceprovider 7015 may transmit the information at predetermined intervals,for example, after the card 3000 transmits a packet of informationindicative of a request for the account information, or the accountinformation can be pushed to the card as soon as it receives theinformation and identifies where the card is in the network, i.e., bysending a location update request to the card 3000.

In at least one other embodiment of the present disclosure, the accountinformation may be transmitted to the card 3000 when the RF module 3201is activated. In this embodiment of operation 8007, the card 3000 userturns on/activates the RF module 3201 in order to receive the accountinformation. This activation may be accomplished by, for example,touching the biometric input area 3007 (or an alternative input area,i.e., transmit/receive button) of the card 3000. In this example, afterthe user touches the biometric input area 3007 the RF module may connectwith the cell tower 7010 to receive the account balance.

As illustrated in operation 8009, the account information can then bedisplayed on the screen(s). The information displayed may be, forexample, account balance, status, recent transaction information,advertisements, a graphic image, any other alert or message, or anycombination of these items. This information may also be stored inmemory on the card for buffering or for a variety of future uses such asto compare old data with new data being received. In some embodiments,the card 3000 may automatically turn off as illustrated by optionaloperation 8011 via a timer to save battery and/or for security purposes.

FIG. 21 illustrates an example operational flow chart in which thewirelessly updated VIN card of FIG. 15 is updated via a card holder'scellular phone 7012. As depicted by operation 9001, a financialinstitution's database is updated with card account information similarto that described above with respect to operation 8001. This accountinformation is transmitted 9002 to a wireless communication serviceprovider. This may be a long range signal service provider 7015, forexample. As shown by operation 9003, the long range signal serviceprovider 7015 can then start transmitting (possibly encrypted) accountinformation to the specific phone number of the cellular phone 7012 orother portable wireless digital device of the account holder. As shownby operation 9004, the cell phone can then store the account informationin, for example, memory of the cellular phone 7012 such as RAM, and thenthe transceiver (not shown) in the cell phone 7012 can starttransmitting the encrypted account information to the card 3000 once thephone and the card are connected to each other as illustrated byoperation 9005 and 9006. For example, in some embodiments of the presentdisclosure, the cellular phone 7012 may include an RFID reader forexample. In this embodiment the card may include a passive, or active,RFID tag that is configured to be reprogrammed with informationtransmitted by the phone when a RFID tag comes within range of the cellphone's RFID tag reader (not shown). Another specific example mayinclude both the cellular phone of the user and the card includingBluetooth adapters. In this example, when the card comes in close rangeof the phone, the two Bluetooth adapters may connect and the phone maytransmit the account information to the card. This account informationis then displayed 9007 on the card 3000, when, for example, the useractivates their card by placing their finger on the biometric reader3007.

FIG. 22 depicts an operational flow chart illustrating an exampleoperational process in which the wirelessly updated VIN card of FIG. 15is updated via, for example, a WiFi, WiMAX, or other local area ormetropolitan area computer network. First, the financial institution's7001 database is updated 2201 with card account information similar tothat described above with respect to operation 8001. As illustrated byoperation 2202, the user may enter an area that includes coverageprovided by one or more routers utilizing technology such as WiMax, orWiFi. Then, as shown by operation 2203, the card 3000, can connect tosuch a network and transmit one or more packets of informationindicative of a request to access the user's account and receive theuser's balance. In some embodiments, this may be accomplished byproviding the card 3000 with hardware, software, or firmware configuredto connect to any available public network and submit a http, or securehttp, request to the router associated with the WiMax or WiFi router inthe coverage area. The router can then submit the request to an internetservice provider (ISP) wherein the ISP may route the request to one ormore other ISPs until the request arrives at a server maintained by thefinancial provider 7001. As shown by operation 2204, the user can bevalidated by the financial provider 7001. In response, the server maytransmit one or more packets of information indicative of accountinformation back throughout the system to the card 3000 as shown byoperation 2205, and thereafter the available balance of the user may bedisplayed on the screen 3001 of the card 3000 as illustrated byoperation 2206.

FIG. 23 depicts an operational flow chart illustrating aspects of thepresent disclosure including biometric security features. In someembodiments of the present disclosure, instead of continuouslydisplaying the information in the display, the screen may displayinformation when the user is authenticated. This reduces the likelihoodthat an unauthorized user will obtain the card number or the balance ofthe account, for example. In this example, the financial institution's7001 database is updated 2301 with card account information. Thisupdated account information is transmitted 2303 to a long range signalservice provider 7015, or in other embodiments accessible through aninternet connection provided by a WiMAX network for example. As depictedby operation 2305, the long range signal service provider 7015 cantransmit (possibly encrypted) account information to the specific phonenumber/or network address of the card 3000. At some point, the card usercan turn on/activate 2307 the card 3000 to receive the accountinformation through the wireless transceiver 3201 in the card 3000. Thisactivation may be accomplished, for example, by touching the biometricinput area 3007 (or an alternative input area) of the card 3000, Thebiometric data captured by the biometric reader (e.g., thumbprint reader3205) can then be stored, for example, temporarily on the card memorymodule 3203. The card can then send 2309 biometric data via the longrange signal service provider 7015, or the internet connectionmaintained by a router(s) 7020 associated with a local area network tothe financial institution 7001. The financial institution 7001 can thenverify 2311 the biometric data (the card holder having previouslyprovided their biometric data to the financial institution for securitypurposes). The financial institution can then send 2313 a signal to thecard 3000 via the long range long range signal service provider 7015 forexample, to allow account information to be displayed. The receivedaccount information is then displayed 2315 on the display 3001. Theinformation received and/or displayed on the display 3001 may be, forexample, account balance, status, recent transaction information,advertisements, a graphic image, any other alert or message, or anycombination of these items. This information may also be stored inmemory on the card for buffering or for a variety of future uses such asto compare old data with new data being received. Optionally, the card3000 may automatically turn off 2317 via a timer used by the cardprocessor 3104 to save battery and/or for security purposes.

Operational flow 2400 of FIG. 24 illustrates an example operational flowthat depicts biometric security features of the present disclosure. Forexample, as illustrated by FIG. 22, operation 2401 illustrates a userentering their biometric information. As discussed earlier, biometricinformation may include, but is not limited to, the user's thumbprint,voice profile, facial features, or any other biometric information. Asshown by operation 2402, the biometric receiver on the card 3000 mayreceive the information and, in some embodiments, process theinformation utilizing the card's 3104 microprocessor in order todetermine if the user is authorized. For example, when the card 3000 isissued to the user, the issuer (the financial services provider 7001)may capture the thumbprint or take a picture of the user. In thisexample, the image of the print or user can be digitized and stored inthe card's memory 3203, i.e., in nonvolatile read only memory. When theinformation is received by the biometric receiver 3205 it may process(utilizing the processor 3104) the information and attempt to match thereceived image to the image stored in memory 3203 using a matchingalgorithm or technique as shown by operation 1202. As shown by operation2404, in the event that the user is authorized, i.e., the biometricinformation of the user matches the stored digital file, the display3001, 3002, 3003, etc. of the card may be energized and display anyinformation otherwise the operational procedure may stop at 2403. Asillustrated by operation 2405, some information may not need to beupdated such as the account number, expiration date, user's signature,etc. This type of information may be immediately displayed in the screenin operation 2406. Other type of account information, such as theavailable balance of the user may need to be updated before it can bedisplayed. In this situation, the RF transceiver 3201 of the card can beactivated at 2407 and the updated account information may be received at2408 before being displayed to the user

The foregoing detailed description has set forth various embodiments ofthe systems and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and/or operationwithin such block diagrams, flowcharts, or examples can be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or virtually any combination thereof.

The various systems, methods, and techniques described herein may beimplemented with hardware or software or, where appropriate, with acombination of both. Thus, the methods and apparatus of the presentdisclosure, or certain aspects or portions thereof, may take the form ofprogram code (i.e., instructions) embodied in tangible media, such asfloppy diskettes, CD-ROMs, hard drives, or any other machine-readablestorage medium, wherein, when the program code is loaded into andexecuted by a machine, such as a computer, the machine becomes anapparatus for practicing the invention. In the case of program codeexecution on programmable computers, the computer will generally includea processor, a storage medium readable by the processor (includingvolatile and non-volatile memory and/or storage elements), at least oneinput device, and at least one output device. One or more programs arepreferably implemented in a high level procedural or object orientedprogramming language to communicate with a computer system. However, theprogram(s) can be implemented in assembly or machine language, ifdesired. In any case, the language may be a compiled or interpretedlanguage and combined with hardware implementations.

The methods of the present invention may also be embodied in the form ofprogram code that is transmitted over some transmission medium, such asover electrical wiring or cabling, through fiber optics, or via anyother form of transmission, wherein, when the program code is receivedand loaded into and executed by a machine, such as an EPROM, a gatearray, a programmable logic device (PLD), a client computer, a videorecorder or the like, the machine becomes an apparatus for practicingthe disclosure. When implemented on a general-purpose processor, theprogram code combines with the processor to provide a unique apparatusthat operates to perform the functionality of the systems and methodsdescribed herein.

While the present invention has been described in connection with thepreferred embodiments of the various figures, it is to be understoodthat other similar embodiments may be used or modifications andadditions may be made to the described embodiment for performing thesame function of the present invention without deviating there from.Furthermore, it should be emphasized that a variety of computerplatforms, including handheld device operating systems and otherapplication-specific hardware/software interface systems, are hereincontemplated, especially as the number of wireless networked devicescontinues to proliferate. Therefore, the present invention should not belimited to any single embodiment, but rather construed in breadth andscope in accordance with the appended claims.

What is claimed:
 1. A vehicle identification card, comprising: a cardbody; a processor attached to the card body; a transceiver operablycoupled to the processor; a biometric input area operably coupled to theprocessor; a display physically attached to the card body andcommunicatively coupled to the processor; and a memory storing firstdata identifying a vehicle and instructions that cause the processor toeffectuate operations, the operations comprising: receiving, via thebiometric input area, a user input; in response to the receiving theuser input via the biometric input area, establishing a wirelessconnection with a device external to the vehicle identification card;receiving, via the wireless connection and from the device external tothe vehicle identification card, second data associated with thevehicle; transferring the second data associated with the vehicle to anexternal system; and displaying a representation based on at least aportion of the first data or the second data.
 2. The vehicleidentification card of claim 1, wherein the user input is indicative ofan activation of the vehicle identification card.
 3. The vehicleidentification card of claim 1, wherein the biometric input areacomprises at least one of a fingerprint reader, a voiceprint reader, ora facial feature data reader.
 4. The vehicle identification card ofclaim 1, wherein the display comprises at least one of a light-emittingpolymer display or a liquid crystal display.
 5. The vehicleidentification card of claim 1, wherein the display comprises atouch-sensitive display.
 6. The vehicle identification card of claim 1,further comprising at least one additional display.
 7. The vehicleidentification card of claim 1, wherein the transceiver comprises atleast one of a cellular transceiver, a Bluetooth transceiver, a Wi-Fitransceiver, or an RFID tag.
 8. The vehicle identification card of claim1, wherein the transceiver comprises an antenna.
 9. The vehicleidentification card of claim 8, wherein the antenna comprises a cellularantenna.
 10. The vehicle identification card of claim 1, wherein thesecond data comprises charge account information of a user of thevehicle.
 11. The vehicle identification card of claim 10, wherein thecharge account information is associated with a fund for repairs of thevehicle.
 12. The vehicle identification card of claim 1, wherein thesecond data comprises proof of insurance information related to thevehicle.
 13. The vehicle identification card of claim 1, furthercomprising a battery.
 14. The vehicle identification card of claim 13,further comprising photovoltaic cells for providing power to the batterywhen the vehicle identification card is exposed to light.
 15. Thevehicle identification card of claim 1, wherein the operations furthercomprise, based on the user input, authenticating the user; and whereinthe establishing the wireless connection with the device external to thevehicle identification card is based at least on the authenticating theuser.
 16. A transaction card comprising: a card body; a processorattached to the card body; an electronic display attached to the cardbody; and a memory storing first data associated with a vehicle andinstructions that cause the processor to effectuate operations, theoperations comprising: transmitting, via a wireless network, a requestfor second data associated with the vehicle, the request comprising anidentification of a user of the vehicle; receiving, via the wirelessnetwork, the second data; transferring the second data to an externalsystem; and displaying a representation, based on at least a portion ofthe first data or the second data, on the electronic display.
 17. Thetransaction card of claim 16, wherein the second data comprisesinformation associated with a charge account of the user and therepresentation comprises a balance associated with the charge account.18. The transaction card of claim 17, wherein the charge accountcomprises at least one of an insurance policy, a line of credit, oraccount funds.
 19. The transaction card of claim 16, wherein the firstdata comprises a proof of insurance of the vehicle.
 20. The transactioncard of claim 16, further comprising a unified thin card assemblycomprising: a first layer comprising the memory; and a second layercoupled to the first layer, the second layer comprising the display.